An operating system performs various tasks relating to a computer system, including managing its hardware and software resources. Hardware resources include processors, primary storage (e.g., memory), secondary storage (e.g., hard disk or optical disk), printers, display adapters, network interface cards, input/output ports, etc. Software resources include application programs, user interfaces, device drivers, network protocol stacks, etc. The operating system manages and coordinates these resources to complete various tasks, such as under the direction of an application program.
Operating systems may provide functionality to application programs using subsystems. A subsystem is an operating system component that implements an operating system's application program interfaces (“APIs”). Subsystems may invoke functions of a kernel component. A kernel component is an operating system component that provides core operating system functions.
An operating system may comprise multiple subsystems, each exposing different operating system behaviors. As an example, an operating system may implement a portable operating system interface (“POSIX”) and a MICROSOFT WINDOWS interface as two separate subsystems. These subsystems may both function on a common operating system. Such an operating system may function both with applications designed for POSIX and applications designed for MICROSOFT WINDOWS.
However, applications designed for one subsystem may not share resources designed for another subsystem. As an example, a POSIX application may be unable to load a dynamic link library (“DLL”) designed for MICROSOFT WINDOWS. Similarly, a MICROSOFT WINDOWS application may be unable to load a DLL designed for POSIX. To enable a DLL designed for a subsystem to function with another subsystem, a developer could rebuild the DLL for the other subsystem. However, rebuilding a DLL may require source code relating to the DLL. The source code may be unavailable when, e.g., the DLL is provided by a software vendor.
As an example, a customer having a UNIX-based application may wish to make the application function with MICROSOFT WINDOWS. This application may have a portion developed by the customer and a portion provided by a software vendor, such as a database software vendor. The customer could then move the portion it developed to POSIX as an intermediate step to moving its applications to MICROSOFT WINDOWS. However, although the software vendor may make available its portion for MICROSOFT WINDOWS as a DLL, it may not make its portion available for POSIX. Because the POSIX portion of the customer's application cannot use the software vendor's DLL designed for MICROSOFT WINDOWS, the customer's application may not fully function with the POSIX subsystem. The customer may thus be less inclined to move its applications to MICROSOFT WINDOWS. It would thus be highly desirable to enable inter-subsystem resource sharing